Database consolidation involves distributing and sharing computing resources among multiple databases. In non-consolidated databases, database backup and recovery may be performed on a per-database basis. However, in a consolidated database or other in-database virtualizations capable of consolidating multiple databases, traditional database backup and recovery practices cannot be carried out on a per-database basis with the same behavior expected of a non-consolidated database.
In a consolidated database, such as a multitenant container database (CDB), a database server instance serving a particular pluggable database (PDB) can handle certain PDB-specific failures with fully managed closure of the PDB (i.e., persisting any changed data to disk in the process of closing the PDB connection). However, some circumstances require forceful closure of a PDB, where the closure does not involve disk access.
Generally, all locks obtained by the database server instance (including locks pertaining to PDB-specific media) belong to the instance. As such, locks obtained for individual PDBs being served by the database server instance are managed jointly as belonging to the instance (or to a distributed lock manager (DLM) domain to which all locks obtained by the instance are scoped). Under these conditions, in order to forcefully close any portion of the locks obtained by the instance, the entire instance is terminated thereby exiting the instance's DLM domain and terminating all locks that are scoped to that instance's DLM domain.
In other words, because all locks obtained by a database server instance are managed jointly, forcefully closing only an individual PDB that has failed is generally infeasible because, in a shared-everything cluster configuration, the buffer cache for the instance may contain dirty buffers belonging to the failed PDB. These dirty buffers cannot be written to disk as part of the forceful closure of only the failed PDB because the specific individual PDB failure may be that the database instance loses connectivity to the storage where the specific PDB's data are stored. If these dirty buffers are discarded instead, without recovery of required changes lost in the discarded buffers, changes based on stale block versions from other cluster nodes would cause logical inconsistency.
Crashing a database server instance because of a PDB-specific failure has many disadvantages, including unnecessarily reducing the availability of all of the properly-functioning PDBs served by the crashed instance. It would be beneficial to allow a database server instance to forcefully close a failed PDB, being served by the instance, without affecting the availability of the other PDBs being served by the database server instance. Furthermore, it would be beneficial to enable database systems to automatically recover PDBs that have been forcefully closed.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.